Robotic process automation bot operational management system

ABSTRACT

A device includes a processor and a memory. The processor effectuates operations including monitoring enterprise network traffic associated with one or more user device (UE). The processor further effectuates operations including comparing the enterprise network traffic to a UE profile associated with each of the one or more UE. The processor further effectuates operations including determining whether the comparison indicates that a predetermined threshold has been exceeded. The processor further effectuates operations including in response to the indication that the predetermined threshold has been exceeded, generating an alert, wherein exceeding the predetermined threshold is indicative of a denial of service attack on an enterprise network or an attempt to remove enterprise data via the one or more UE.

CROSS REFERENCE TO RELATED APPLICATION

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 17/094,406, filed on Nov. 10, 2020. All sections ofthe aforementioned application are incorporated herein by reference intheir entirety.

TECHNICAL FIELD

This disclosure is directed to a system and method for managingtelecommunications networks, and, more specifically, to managing roboticapplication processes operating in networks.

BACKGROUND

Service providers are able to provide a broad array of network-basedservices that include video, telephone, cellular, data and otherservices. Such services require extensive network infrastructure andcustomer premises equipment, which increases the vulnerability of suchservices to outages and other disruptions. Service providers maytroubleshoot network technologies or equipment and repair ofnetwork-based services. The service providers may employ BOTs (e.g.,robotic process automation (RPA) or computer-generated agents) to runautomated tasks within the network. For example, the service providersmay use computer-generated agents to provide a rudimentary monitoringfor the network technologies and equipment in order to obtain insightinto operations. The computer-generated agents may provide informationthat may be used during troubleshooting or repair. Other business typesother than service providers may also use computer-generated agents toperform automated tasks.

This background information is provided to reveal information believedby the applicant to be of possible relevance. No admission isnecessarily intended, nor should be construed, that any of the precedinginformation constitutes prior art.

SUMMARY

Disclosed herein is a device having a processor and a memory coupledwith the processor. The processor effectuates operations includingdeploying one or more robotic process automation (RPA) BOTs in atelecommunications network. The processor further effectuates operationsincluding updating, for the one or more RPA BOTs, a database with BOTinformation comprising at least one of: BOT status update information, adebug log, or BOT operations. The processor further effectuatesoperations including analyzing a status of the one or more RPA BOTsbased on updating the database. The processor further effectuatesoperations including managing the one or more RPA BOTs based on thestatus.

Disclosed herein is a computer-implemented method. Thecomputer-implemented method includes deploying one or more roboticprocess automation (RPA) BOTs in a telecommunications network. Thecomputer-implemented method further includes updating, for the one ormore RPA BOTs, a database with BOT information comprising at least oneof: BOT status update information, a debug log, or BOT operations. Thecomputer-implemented method further includes analyzing a status of theone or more RPA BOTs based on updating the database. Thecomputer-implemented method further includes managing the one or moreRPA BOTs based on the status.

Disclosed herein is a computer-readable storage medium storingexecutable instructions that when executed by a computing device causesaid computing device to effectuate operations including deploying oneor more robotic process automation (RPA) BOTs in a telecommunicationsnetwork. Operations further include updating, for the one or more RPABOTs, a database with BOT information comprising at least one of: BOTstatus update information, a debug log, or BOT operations. Operationsfurther include analyzing a status of the one or more RPA BOTs based onupdating the database. Operations further include managing the one ormore RPA BOTs based on the status.

BRIEF DESCRIPTION OF THE DRAWINGS

Aspects of the herein described telecommunications network and systemsand methods are described more fully with reference to the accompanyingdrawings, which provide examples. In the following description, forpurposes of explanation, numerous specific details are set forth inorder to provide an understanding of the variations in implementing thedisclosed technology. However, the instant disclosure may take manydifferent forms and should not be construed as limited to the examplesset forth herein. Where practical, like numbers refer to like elementsthroughout.

FIG. 1 is a block diagram of an exemplary operating environment inaccordance with the present disclosure;

FIG. 2 is a schematic of an exemplary network device in accordance withthe present disclosure;

FIG. 3 is a schematic of an exemplary system architecture in accordancewith the present disclosure;

FIG. 4 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 5 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 6 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 7 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 8 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 9 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 10 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 11 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 12 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 13 is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 14A is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 14B is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 15A is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 15B is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 15C is an exemplary dashboard in accordance with the presentdisclosure;

FIG. 16 is a flowchart of an exemplary method of operation for thearchitecture in accordance with the present disclosure;

FIG. 17 is a schematic of an exemplary network device;

FIG. 18 depicts an exemplary communication system that provide wirelesstelecommunication services over wireless communication networks withwhich edge computing node may communicate;

FIG. 19 depicts an exemplary communication system that provide wirelesstelecommunication services over wireless communication networks withwhich edge computing node may communicate; and

FIG. 20 is an example system diagram of a radio access network and acore network with which edge computing node may communicate.

DETAILED DESCRIPTION

Network support sites can have various degrees of complexity. Atelecommunications network may include equipment with substantiallydisparate functionality and operational and maintenance requirements. Inaddition, network sites may provide telecommunication signals accordingto various technology protocols and operate disparate ensuing equipment.Thus, conventional management of complex network sites readily becomescumbersome and cost ineffective in view of the various device-specificinterfaces and applications, and communication links.

Conventional telecommunications network management or general businessmanagement provide no insight, real-time or otherwise, into roboticapplication processes (RPA) BOTs, hereinafter “BOTs”, operating (e.g.,batch record processing, reporting, virtual agent, or dataentry/retrieval) within the telecommunications network or manageautomation, an individual BOT or multiple BOTs, at a level toeffectively produce expected and consistent results. Also, the currenttelecommunications network management provides no visibility into howsuccessful BOTs are running and what errors are occurring. Additionally,the current telecommunications network management fail to provide alertswhen key performance indicators (KPIs) thresholds for any of the BOTshave been crossed. Moreover, BOT management is tedious becausetechnicians often have to manually test bot operations, which is timeconsuming.

Accordingly, BOT failures, BOT interruptions, BOT underutilization, BOTover utilization, poor BOT performance, etc., may not be known leadingto delays in or failure to address telecommunications network issues,which could result in poor network performance. By obtaining statusinformation for BOTs, which could be real-time status information,troubleshooting or reporting for BOTs within the telecommunicationsnetwork may occur faster.

The present disclosure includes providing operational oversight ofrobotic process automation (RPA) BOTs running in a telecommunicationsnetwork, which provide insight into RPA BOTs processes. Accordingly,this insight may be utilized to perform BOT management of the RPA BOTs.

FIG. 1 illustrates an example telecommunication system 100 that may beutilized to facilitate operational management processes according to anexemplary embodiment of the present disclosure. As shown in FIG. 1 ,user device (UE) 110 may request a service, execute an application,perform an operation, provide status information, or the like, via radioaccess technology 125 (e.g., an LTE RAN or 5G RAN) and atelecommunications network 101. As depicted in FIG. 1 , UE 110 maycomprise any appropriate type of user device, such as, for example, atablet, personal computer, a laptop computer, or a mobile device, or thelike. The UE 110 may include a display 114 and a graphical userinterface 112. In some example embodiments, data may be provided to thegraphical user interface 112 (e.g., for presentation/output) by acommunication device (e.g., the network support system 120, the BOTmanagement system 105, the backend database 130, etc.).

The UE 110 may include a graphical user interface 112. In some exampleembodiments, the graphical user interface 112 may include an input anddisplay interface that may be used to interact with tools that allowusers to manage robotic application processes in real-time. Roboticapplication processes may provide process automation using softwarerobots (BOTs), as well as artificial intelligence. The BOTs may performtasks ranging from helping technicians activate equipment for customers,aggregating data for service orders, customer service reports, scanningphone calls, compiling network traffic reports, creating engineeringwork orders, and updating systems for network-boosting activities, orother network related operations. Robotic process automation (RPA) isthe application of configured software that allows computer software ora “robot” to capture and interpret existing applications for processinga transaction, manipulating data, triggering responses, or communicatingwith other digital systems. In some other example embodiments, the userinput interface may detect input and selection of a workflow forgenerating and managing robotic application processes, which are furtherdescribed below. It is to be understood that the UE 110 as depicted inFIG. 1 is exemplary and not intended to be limiting.

UE 110 may gain access to the telecommunications network 101 via anyappropriate mechanism. For example, as depicted in FIG. 1 , access tothe telecommunications network 101 may be provided via cellularinfrastructure, Wi-Fi infrastructure, hot spots, or the like, or anyappropriate combination thereof.

The telecommunications communication network 101 may include a softwaredefined network (SDN). The SDN network may be controlled by one or moreSDN controllers. For example, the SDN network may include an SDNcontroller. The SDN controller may be a computing system executingcomputer executable instructions and/or modules to provide variousfunctions. In one or more embodiments, multiple computer systems orprocessors may provide the functionality illustrated and describedherein with respect to the SDN controller. The SDN controller mayinclude various components and/or can be provided via cooperation ofvarious network devices or components. For example, SDN controller mayinclude or have access to various network components or resources, suchas a network resource controller, network resource autonomouscontroller, a service resource controller, a service controlinterpreter, adapters, application programming interfaces, compilers,and network data collection and/or analytics engine (not shown). The SDNcontroller may also include access information describing availableresources and network information, such as network objects statistics,events or alarms, topology, and state changes. The SDN controller mayuse, generate, or access system configurations, including configurationof resources available to the SDN controller for providing access toservices.

The telecommunications communication network 101 may be provided with acommon control plane function. The common control plane can capturetraffic entering the telecommunications communication network 101 fromvarious communication devices (e.g., UE 110) that enters thetelecommunications network 101 via one or more air interfaces.

The SDN Controller is an application in a software-defined network thatmanages flow control to enable intelligent networking. The SDNcontroller may allow servers to tell switches where to send packets. TheSDN controller may also analyze requested services to determine theservice functions and or network data flows that would be required tofacilitate delivery of the services to the UE 110.

The SDN controller may determine what specific network functions arerequired to facilitate services requested from the UE 110. The SDNcontroller may also analyze policies for the requested services. Thepolicies may include network engineering rules, which can be defined bya network designer, engineer (e.g., network support engineer ortechnician), business unit, operations personnel, or the like, or asubscriber policy, which can be defined during ordering of the service.Subscriber policies can include, for example, service level agreements(“SLAs”), location restrictions (e.g., locations at which the servicesare allowed or not allowed), bandwidth ranges, time restrictions (e.g.,times of day, days of week, or other times at which the service isallowed or not allowed), security restrictions or policies, combinationsthereof, or the like.

The network support system 120 may be associated with platforms that aidtelecommunications service providers in managing networks, customerservices, customer experience, service provisioning, networkconfiguration, fault management, inventory management, and ordermanagement. Network engineers and network specialist may interact withthe network support system 120 to monitor, analyze, maintain,troubleshoot, and evaluate computer network problems. The networksupport system 120 may be used to generate workflows including workflowinformation, via, for example, a workflow management interface, andallow network support staff to use the workflow information to creatework orders, open service tickets, and otherwise schedule technicalsupport for a variety of network devices and systems. The workflowinformation may be generated at various times. The workflow informationmay indicate resources associated with a process, how capacity of theresources is used to perform the process, times during the process atwhich the capacity changes begin, occur, end, combinations thereof, orthe like. The workflow information may be stored in a flat file, whichmay be transmitted to the BOT management system 105. Workflows (e.g., aplatform that provides instructions to BOTs as they work to obtaininsight into network or business operations in accordance with theinstructions provided) may be used to address a variety of problems orobtain a variety of information, for example, problem resolution flows,home diagnostic flows, network diagnostic flows, or any combinationthereof.

The BOT management system 105 may include one or more virtual machines(VMs). Each VM may encapsulate a complete set of virtual hardwareresources, including an operating system and all its applications,inside a software package. The VMs may be operated in a headless modethereby allowing the virtual machine to run in the background. Becausethe VMs operate in a headless environment, visibility into BOToperations is limited because BOT operations also run in the backgroundand are not visible (e.g., via a graphical user interface).

The BOT management system 105 may receive one or more flat files fromthe network support system 120. The BOT management system 105 may usethe VMs to generate, monitor, control and provide remote management ofBOTs.

The BOTs may be generated as virtual instances (e.g., Virtual NetworkFunctions (VNFs), VMs or virtual network resources), which may be usedto perform automated tasks to or within the telecommunicationscommunication network 101 assigned by network support staff which may bebased on pre-defined rules and instructions. The BOTs may perform tasks,such as helping technicians activate equipment for customers,aggregating data for service orders and customer service reports,creating engineering work orders, or updating systems fornetwork-boosting activities. For example, BOTs may be used to scan phonecalls to customer service and compile network traffic reports. The tasksmay be one or more actions to be performed to the network or to one ormore BOTs (e.g., start BOT, stop BOT, schedule BOT, monitor BOT, rebootBOT, update BOT, clear hung session, BOT run record success/fail, howsuccessful is a BOT running, what is causing BOT failures, what iscausing a record processing failure, determine whether to identify inputdata is in place, identify whether a hosted virtual disk (HVD) is readyfor use, identify whether a HVD is logged into a BOT server, identifywhether a BOT is ready to run, identify key performance indicators(KPIs) per BOT, identify errors in real-time, identify record failurecauses, identify captured failed records, automate a fallout rerun(KPI), perform BOT analytics, debug analytics, and reboot server orHVD). The BOTs may also be used to collect and analyze data from thenetwork and the resources and functions, and compare the data toengineering rules, policies, network maps, SLAs, and other analytics todetermine how performance compares to desired standards.

The user device 110 may utilize the graphical user interface 112 (e.g.,a dashboard providing a screen that receives and displays information)to enable an operator to search on a wide range of parameters in thedatabase. For example, the user device 110 may be used to search for orotherwise manage the BOTs based on, for example, a BOT status, BOTlocation, BOT KPI, BOT failure, BOT analytics, etc. The BOT status maybe, for example, start, stop, scheduled, running, etc. The BOT status,BOT location, BOT KPI, BOT failure, and BOT analytics may be stored inthe backend database 130. The graphical user interface 112 may be usedto visualize a variety of aspects that provides visibility into theoperation of BOTs that have been deployed within the telecommunicationscommunication network 101. For example, the graphical user interface 112may display a dashboard for at least one of: a BOT schedule, astart/stop BOT status, running BOT view, view of records beingprocessed, view of success/fail processing for each record, BOT KPI withKPI alerting, real-time reporting and analytics, BOT errors, BOTperformance, HVD readiness, HVD capacity management, record basedcall-driver dashboard, mobile application testing BOT, BOT managementemail/messenger alerting.

Accordingly, the BOT management system 105 may be used to manage one ormore BOTs running on one or more HVDs (e.g., 30 HVDs). The user device110 may be utilized to provide a real-time view of the BOTs running,what the BOTs are running, and how well the BOTs are performing.

The backend database 130 may be used to store a variety of informationgenerated or received by the network support system 120, BOT managementsystem 105, and user device 110. The backend database 130 may storeinformation relating to tasks that have been performed in the past byBOTs. The backend database 130 may include a repository of tasks and arepository of feedback associated with one or more BOTs. The repositoryof tasks may include information about previously performed tasks. Thisinformation may include the nature of the task performed, which BOTperformed the task, the time at which the task was performed, etc. Therepository of feedback may include feedback from network support staffin response to the tasks performed. For instance, this feedback mayindicate whether the tasks were completed to satisfaction or whetherimprovements for completing the tasks are needed. Feedback may alsoindicate whether any problems were encountered in performing the tasksand what actions were taken to resolve the problems.

FIG. 2 depicts a computing device that may be used in various aspects,such as the servers, modules, and/or devices depicted in FIG. 1 . Withregard to the example architecture of FIG. 1 , the network supportsystem 120, BOT management system 105, and user device 110 may each beimplemented in an instance of a computing device 200 of FIG. 2 . Thecomputer architecture shown in FIG. 2 may illustrate a server computer,workstation, desktop computer, laptop, tablet, network appliance, PDA,e-reader, digital cellular phone, or other computing node, and may beutilized to execute any aspects of the computers described herein, suchas to implement the methods described herein.

The computing device 200 may include a baseboard, or “motherboard,”which is a printed circuit board to which a multitude of components ordevices may be connected by way of a system bus or other electricalcommunication paths. One or more central processing units (CPUs) 204 mayoperate in conjunction with a chipset 206. The CPU(s) 204 may bestandard programmable processors that perform arithmetic and logicaloperations necessary for the operation of the computing device 200.

The CPU(s) 204 may perform the necessary operations by transitioningfrom one discrete physical state to the next through the manipulation ofswitching elements that differentiate between and change these states.Switching elements may generally include electronic circuits thatmaintain one of two binary states, such as flip-flops, and electroniccircuits that provide an output state based on the logical combinationof the states of one or more other switching elements, such as logicgates. These basic switching elements may be combined to create morecomplex logic circuits including registers, adders-subtractors,arithmetic logic units, floating-point units, and the like.

The CPU(s) 204 may be augmented with or replaced by other processingunits, such as GPU(s) 205. The GPU(s) 205 may comprise processing unitsspecialized for but not necessarily limited to highly parallelcomputations, such as graphics and other visualization-relatedprocessing.

A chipset 206 may provide an interface between the CPU(s) 204 and theremainder of the components and devices on the baseboard. The chipset206 may provide an interface to a random-access memory (RAM) 208 used asthe main memory in the computing device 200. The chipset 206 may furtherprovide an interface to a computer-readable storage medium, such as aread-only memory (ROM) 220 or non-volatile RAM (NVRAM) (not shown), forstoring basic routines that may help to start up the computing device200 and to transfer information between the various components anddevices. ROM 220 or NVRAM may also store other software componentsnecessary for the operation of the computing device 200 in accordancewith the aspects described herein.

The computing device 200 may operate in a networked environment usinglogical connections to remote computing nodes and computer systemsthrough local area network (LAN) 216. The chipset 206 may includefunctionality for providing network connectivity through a networkinterface controller (NIC) 222, such as a gigabit Ethernet adapter. ANIC 222 may be capable of connecting the computing device 200 to othercomputing nodes over a network 216. It should be appreciated thatmultiple NICs 222 may be present in the computing device 200, connectingthe computing device to other types of networks and remote computersystems.

The computing device 200 may be connected to a mass storage device 228that provides non-volatile storage for the computer. The mass storagedevice 228 may store system programs, application programs, otherprogram modules, and data, which have been described in greater detailherein. The mass storage device 228 may be connected to the computingdevice 200 through a storage controller 224 connected to the chipset206. The mass storage device 228 may consist of one or more physicalstorage units. A storage controller 224 may interface with the physicalstorage units through a serial attached SCSI (SAS) interface, a serialadvanced technology attachment (SATA) interface, a fiber channel (FC)interface, or other type of interface for physically connecting andtransferring data between computers and physical storage units.

The computing device 200 may store data on a mass storage device 228 bytransforming the physical state of the physical storage units to reflectthe information being stored. The specific transformation of a physicalstate may depend on various factors and on different implementations ofthis description. Examples of such factors may include, but are notlimited to, the technology used to implement the physical storage unitsand whether the mass storage device 228 is characterized as primary orsecondary storage and the like.

For example, the computing device 200 may store information to the massstorage device 228 by issuing instructions through a storage controller224 to alter the magnetic characteristics of a particular locationwithin a magnetic disk drive unit, the reflective or refractivecharacteristics of a particular location in an optical storage unit, orthe electrical characteristics of a particular capacitor, transistor, orother discrete component in a solid-state storage unit. Othertransformations of physical media are possible without departing fromthe scope and spirit of the present description, with the foregoingexamples provided only to facilitate this description. The computingdevice 200 may further read information from the mass storage device 228by detecting the physical states or characteristics of one or moreparticular locations within the physical storage units.

In addition to the mass storage device 228 described above, thecomputing device 200 may have access to other computer-readable storagemedia to store and retrieve information, such as program modules, datastructures, or other data. It should be appreciated by those skilled inthe art that computer-readable storage media may be any available mediathat provides for the storage of non-transitory data and that may beaccessed by the computing device 200.

By way of example and not limitation, computer-readable storage mediamay include volatile and non-volatile, transitory computer-readablestorage media and non-transitory computer-readable storage media, andremovable and non-removable media implemented in any method ortechnology. Computer-readable storage media includes, but is not limitedto, RAM, ROM, erasable programmable ROM (“EPROM”), electrically erasableprogrammable ROM (“EEPROM”), flash memory or other solid-state memorytechnology, compact disc ROM (“CD-ROM”), digital versatile disk (“DVD”),high definition DVD (“HD-DVD”), BLU-RAY, or other optical storage,magnetic cassettes, magnetic tape, magnetic disk storage, other magneticstorage devices, or any other medium that may be used to store thedesired information in a non-transitory fashion.

A mass storage device, such as the mass storage device 228 depicted inFIG. 2 , may store an operating system utilized to control the operationof the computing device 200. The operating system may comprise a versionof the LINUX operating system. The operating system may comprise aversion of the WINDOWS SERVER operating system from the MICROSOFTCorporation. According to further aspects, the operating system maycomprise a version of the UNIX operating system. Various mobile phoneoperating systems, such as IOS and ANDROID, may also be utilized. Itshould be appreciated that other operating systems may also be utilized.The mass storage device 228 may store other system or applicationprograms and data utilized by the computing device 200.

The mass storage device 228 or other computer-readable storage media mayalso be encoded with computer-executable instructions, which, whenloaded into the computing device 200, transforms the computing devicefrom a general-purpose computing system into a special-purpose computercapable of implementing the aspects described herein. Thesecomputer-executable instructions transform the computing device 200 byspecifying how the CPU(s) 204 transition between states, as describedabove. The computing device 200 may have access to computer-readablestorage media storing computer-executable instructions, which, whenexecuted by the computing device 200, may perform methods describedherein.

A computing device, such as the computing device 200 depicted in FIG. 2, may also include an input/output controller 232 for receiving andprocessing input from a number of input devices, such as a keyboard, amouse, a touchpad, a touch screen, an electronic stylus, or other typeof input device. Similarly, an input/output controller 232 may provideoutput to a display 205, such as a computer monitor, a flat-paneldisplay, a digital projector, a printer, a plotter, or other type ofoutput device. It will be appreciated that the computing device 200 maynot include all of the components shown in FIG. 2 , may include othercomponents that are not explicitly shown in FIG. 2 , or may utilize anarchitecture completely different than that shown in FIG. 2 .

As described herein, a computing device may be a physical computingdevice, such as the computing device 200 of FIG. 2 . A computing nodemay also include a virtual machine host process and one or more virtualmachine instances. Computer-executable instructions may be executed bythe physical hardware of a computing device indirectly throughinterpretation and/or execution of instructions stored and executed inthe context of a virtual machine.

FIG. 3 illustrates an exemplary operational diagram 250 for managing RPABOT processes within a network according to the present disclosure.Network support staff operating at a network support center 251 mayoversee (e.g., monitor, analyze, maintain, troubleshoot, or evaluate) acomputer network for problems. Based on the oversight of the network,the network support staff may be used to generate one or more workflows253, which may be used to create work orders, open service tickets, andotherwise schedule technical support for a variety of network devicesand systems. The workflows 253 may be sent to an input file drop 255.The input file drop may involve moving a file(s) to the predeterminedfolder where the file(s) are staged (e.g., at a storage location ordrive) pending the BOT retrieval. One or more input files (e.g., aClarify input file which logs customer ticketing information indicatingissues customers may have encountered while using the telecommunicationsnetwork 101) may be sent from the input file drop 255 to a BOT manager265. The BOT manager 265 may process the one or more input files. Oncethe BOT manager 265 processes the one or more input files, the BOTmanager 265 may generate BOTs (e.g., a Clarify BOT) via the BOTgenerator 261 and schedule BOT operations using a BOT scheduler 257. TheBOT manager 265 may also manage scheduled BOT operations (e.g., startBOT, stop BOT, schedule BOT, monitor BOT, reboot BOT, update BOT, clearhung session, BOT run record success/fail, how successful is a BOTrunning, what is causing BOT failures, what is causing a recordprocessing failure, determine whether identify input data is in place,identify whether a hosted virtual disk (HVD) is ready for use, identifywhether a HVD is logged into a BOT server, identify whether a BOT isready to run, identify key performance indicators (KPIs) per BOT,identify errors in real-time, identify record failure causes, identifycaptured failed records, automate a fallout rerun, perform BOTanalytics, debug analytics, and reboot server or HVD). The BOT manager265 may also transmit failed drop information (e.g., report shows wherevisitors leave (fallout) and continue through (fall-through) apre-specified sequence of pages) to fallout file drop 259, which may beconsidered a KPI. The fallout file drop 259 may transmit falloutinformation to the input file drop 255, on for example, a periodicbasis. The BOT manager 265 may submit to debug logs 267 operations,processes, and errors that occur when the BOTs perform tasks. A database275 (e.g., a backend database) may send or receive data from the BOTmanager 265 (e.g., BOT status update information), debug logs (e.g.,per-record BOT success information, average BOT process duration, BOTerrors, etc.), or other information related to BOT operations). Thedatabase 275 may be used to generate reports 279 (e.g., BOT errorreports, BOT performance reports, etc.), which may be createdautomatically according to a predetermined schedule (e.g., hourly,daily, weekly, etc.) or via a manual request. The database 275 may beused to generate one or more alerts 277 (e.g., email, ticket, messenger,alarm, etc.) in response to a BOT status for one or more BOTs exceedinga predetermined threshold (e.g., a failure rate for a BOT exceeding25%).

The database 275, the alerts 277, or the reports 279 may be used by theBOT management user interface 280, which may be a GUI, to provide areal-time view of BOTs running, what the BOTs are running, and how wellthe BOTs are performing. A plurality of dashboards may be accessed anddisplayed via the BOT management user interface 280. For example, theBOT management user interface 280 may provide at least one of: adashboard view, real-time BOT status, historical BOT status (e.g., past24 Hrs.), regression test-based on-demand BOTs, a call driver dashboard,a BOT list (e.g., a list all BOTs with HVDs), a BOT status (e.g. adashboard listing all jobs or tasks run by the BOTs, an HVD Managementdashboard, an HVD capacity management dashboard, a reporting andanalytics dashboard, and a setting/admin dashboard. The BOT managementuser interface 280 may be used to clear BOT conditions, perform a BOTrestart, HVD or host machine restart, etc.) in response to encounteringa BOT error, a mechanical/HVD error, an API error or other errors, arecord failure, BOT failure status, BOT offline status, BOT hung status,etc.

The BOT management user interface 280 may provide the followinginformation in a variety of dashboards and views:

Dashboard View (see FIGS. 4 and 5 ) may provide real-time KPIs, an inputfile count, fallout file count, last processed hour, BOTs offline,active/idle BOTs, fallout percentage (e.g., last hour), color-basedthreshold alerting, or email KPI alerting and may provide total recordsin a batch file, success/fail status of each record processed, falloutcount, last run time, filename being processed, or HVD processing thefile. BOTs may run a same BOT instance (e.g., Clarify BOT instance) oneach of a plurality of HVDs (e.g., 30 HVDs).

Historical BOT status dashboard (see FIG. 6 )—may provide total recordsin a batch file, success/fail status of each record processed, row colorindicator success/fail, fallout count, last run time, filenameprocessed, or HVD processing the file.

Regression test-based on-demand BOT dashboard (see FIG. 7 )—may providemanagement of regression testing on demand including select and startBOT, user ID, start/end, and a historical list of BOT runs, test statusdelivered in UI, or via text messages, electronic messengerapplications, email, real-time page-by-page viewing in the BOTmanagement user interface 280, test results with screenshotsdownloadable from the BOT management user interface 280. Selection of atest case in this dashboard may allow a user or the BOT managementsystem 105 to select one or more predetermined tests that are run onselected BOT(s). The BOT management system 105 may step through eachportion of the selected one or more predetermined test and indicatewhether the selected BOT(s) test has run successfully or has failed. Ifa failure occurs, failure data (e.g., a screen shot of BOT failure data)may be output via the dashboard. This dashboard may also provide areal-time test status and results 701.

Call driver dashboard (see FIG. 8 )—may provide a graphical display(e.g., running data for a previous time-period against monthly average),a multiple disposition view from selected data, or export raw data.

HVD Capacity Management dashboard (see FIG. 9 )—may provide a listing ofall HVDs with associated MechID, one or more displays indicating acapacity allocated, a monitored capacity, graphical timeline for eachday of the week, a display of BOT runs for the previous 7 daysgraphically, a display of a total available time, a display of freetime, a display of total monitored time, a display of total allocatedtime, or a display of total maintenance time, set/manage BOT run times,or a selectable HVD matrix for a day. Capacity on an HVD may be brokenup into time slots (e.g., 15 min slots). For example, if a BOT isidentified as requiring two hours to complete a task, the BOT mayutilize eight time slots leaving the remainder of the day available. TheHVD Capacity Management dashboard may provide a graphical view ofscheduled and available timeslots, which may be used for identificationand decision making when rescheduling or adding new BOTs to an HVDschedule. Accordingly, this dashboard may provide an indication of HVDunderutilization and HVD over utilization, which may be used to add oneor more BOTs when the HVD is underutilized or remove one or more BOTsfrom an HVD when the HVD is over utilized.

BOT status dashboard (see FIG. 10 ) may provide current BOTs offlineincluding last run time, current running BOTs, historical BOT runsincluding total records in batch file, success/fail status of eachrecord processed, last run time, or HVD/Mech processing file.

HVD Management dashboard (see FIG. 11 ) may provide a listing of allHVDs with associated MechID including a selectable status, an adminwaiver, a password change date, a password long life indicator, passwordexpiring email alerts, a status note, or an HVD screen resolution.

Reporting and analytics dashboard (see FIGS. 12-14B) may provide alertsand selectable reports including report for current day, report foryesterday, user selected report, or quarterly BOT run calculationincluding a report consolidating all runs into a quarterly/yearly view,an RPA dashboard report including HVD/Mech processing, BOT name,success/fail counts, fallout percentage, an average per-record duration,or color-based thresholding, critical BOT debug reports includingHVD/Mech processing, a time stamp, a fail point, an error snapshot filename and location, a code line failure, or error debug file name andlocation, a debug error matrix including total errors by Mech/HVD or alisting all errors that have occurred. For example, in FIG. 12 , the BOTmanagement user interface 280 may provide an alert indicating an errorcause (e.g., an email address was not available causing a Yoda error tooccur when implementing a Yoda conditional statement). In addition tothe alert and cause of the error, the BOT management user interface 280may provide a recommendation action (e.g., clear and restart an HVD orcreate a trouble ticket) to the technical staff or the BOT managementsystem 105 may perform the recommended action.

BOT list dashboard (see FIG. 15A) may provide a list all BOTs with anHVD and MechID, last known BOT status, button driven BOT commandsincluding start BOT, stop BOT, reload BOT, enable HVD to BOT runnerapplication program interface (API), or disable HVD to BOT runner API, atoggle button—view state (e.g., real-time BOTs), or a toggle button—viewstate (e.g., HVDs enabled on BOT runner).

Setting/admin dashboard (see FIGS. 15B and 15C) may provide a usersetting page including a default start page, a default compact/expandedview or reporting color-based threshold settings, a server setting pageincluding a fallout threshold setting by BOT, an input folder alert, arerun file check alert, or scheduled run check alerts. FIG. 15B may beused for server settings and FIG. 15C may be used for user settingsassociated with a given user.

An exemplary operational flowchart in accordance with a method of thepresent disclosure is illustrated in FIG. 16 , which may be utilized formanaging RPA BOT processes within a network. At block 1605, a BOTmanagement system 105 may generate or otherwise deploy one or more BOTswithin a telecommunications network. The one or more BOTs may begenerated in response to one or more workflows received from a networksupport system 120. At block 1610, the BOT management system 105 maystart the one or more BOTs. For example, the one or more BOTs mayprovide a start notification in response to a selection of one or morepredetermined tests or other tasks via the BOT management system 105.

At block 1615, the BOT management system 105 may update a database inresponse to sending or receiving data from the BOT manager 265 (e.g.,BOT status update information, debug logs, or other information relatedto BOT operations. For example, the updated data may be related to atleast one of: file name and record information associated with the oneor more BOTs (e.g., record count information), record successes andfailures (e.g., whether or not a record successfully, added, updated,changed) associated with the one or more BOTs, error reports associatedwith the one or more BOTs (e.g., a report indicating that a clarifywindow could not be found causing the one or more BOTs to drop a recordin a file to be rerun (fallout), closing applications, and causing theone or more BOTs to use a next record in the file), or an end of fileassociated with the one or more BOTs.

At block 1620, the BOT management system 105 may analyze statusinformation associated with the one or more BOTs. The status informationmay be related to real-time statuses, historical statuses, teststatuses, last known status, success/fail status, HVD status, etc. Atblock 1625, the BOT management system 105 may provide the statusinformation associated with the one or more BOTs via a BOT managementdashboard. At block 1630, the BOT management system 105 may manage theone or more BOTs based on the analysis performed at block 1620 or viainput received through the BOT management dashboard. The management ofthe one or more BOTs may include performing one or more actions on theone or more BOTs or telecommunications network (e.g., start Bot, stopBOT, schedule BOT, monitor BOT, reboot BOT, update BOT, clear hungsession, BOT run record success/fail, how successful is a BOT running,what is causing bot failures, what is causing a record processingfailure, determine whether identify input data is in place, identifywhether a hosted virtual disk (HVD) is ready for use, identify whether aHVD is logged into a BOT server, identify whether a BOT is ready to run,identify key performance indicators (KPIs) per BOT, identify errors inreal-time, identify record failure causes, identify captured failedrecords, automate a fallout rerun (KPI), perform BOT analytics, debuganalytics, and reboot server or HVD).

Accordingly, the present disclosure provides a system that may monitorand implement robotic process automation (RPA) BOTs. The system maycommunicate with a backend database and user interface to create anend-to-end communication that provides insight into quality, quantity,success/failure, start/stop, and errors of RPA BOT processes. The systemmay manage the RPA BOTs and cause the RPA BOTs to perform one or moretasks or actions. By monitoring and managing the RPA BOTs, may occur inreal-time, the system may identify BOT failures, BOT interruptions, BOTunderutilization, BOT over utilization, poor BOT performance, etc.,which may be used for troubleshooting and reporting associated with theRPA BOTs. Using the identification, the system may address potential oractual delays in or failures to a telecommunications network in order tomaintain or improve telecommunications network performance.

FIG. 17 is a block diagram of network device 300 that may be connectedto or comprise a component of edge computing node or connected to edgecomputing node via a network. Network device 300 may comprise hardwareor a combination of hardware and software. The functionality tofacilitate telecommunications via a telecommunications network mayreside in one or combination of network devices 300. Network device 300depicted in FIG. 17 may represent or perform functionality of anappropriate network device 300, or combination of network devices 300,such as, for example, a component or various components of a cellularbroadcast system wireless network, a processor, a server, a gateway, anode, a mobile switching center (MSC), a short message service center(SMSC), an ALFS, a gateway mobile location center (GMLC), a radio accessnetwork (RAN), a serving mobile location center (SMLC), or the like, orany appropriate combination thereof. It is emphasized that the blockdiagram depicted in FIG. 17 is exemplary and not intended to imply alimitation to a specific implementation or configuration. Thus, networkdevice 300 may be implemented in a single device or multiple devices(e.g., single server or multiple servers, single gateway or multiplegateways, single controller, or multiple controllers). Multiple networkentities may be distributed or centrally located. Multiple networkentities may communicate wirelessly, via hard wire, or any appropriatecombination thereof.

Network device 300 may comprise a processor 302 and a memory 304 coupledto processor 302. Memory 304 may contain executable instructions that,when executed by processor 302, cause processor 302 to effectuateoperations associated with mapping wireless signal strength.

In addition to processor 302 and memory 304, network device 300 mayinclude an input/output system 306. Processor 302, memory 304, andinput/output system 306 may be coupled together (coupling not shown inFIG. 17 ) to allow communications therebetween. Each portion of networkdevice 300 may comprise circuitry for performing functions associatedwith each respective portion. Thus, each portion may comprise hardware,or a combination of hardware and software. Input/output system 306 maybe capable of receiving or providing information from or to acommunications device or other network entities configured fortelecommunications. For example, input/output system 306 may include awireless communications (e.g., 3G/4G/GPS) card. Input/output system 306may be capable of receiving or sending video information, audioinformation, control information, image information, data, or anycombination thereof. Input/output system 306 may be capable oftransferring information with network device 300. In variousconfigurations, input/output system 306 may receive or provideinformation via any appropriate means, such as, for example, opticalmeans (e.g., infrared), electromagnetic means (e.g., RF, Wi-Fi,Bluetooth®, ZigBee®), acoustic means (e.g., speaker, microphone,ultrasonic receiver, ultrasonic transmitter), or a combination thereof.In an example configuration, input/output system 306 may comprise aWi-Fi finder, a two-way GPS chipset or equivalent, or the like, or acombination thereof.

Input/output system 306 of network device 300 also may contain acommunication connection 308 that allows network device 300 tocommunicate with other devices, network entities, or the like.Communication connection 308 may comprise communication media.Communication media typically embody computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism and includesany information delivery media. By way of example, and not limitation,communication media may include wired media such as a wired network ordirect-wired connection, or wireless media such as acoustic, RF,infrared, or other wireless media. The term computer-readable media asused herein includes both storage media and communication media.Input/output system 306 also may include an input device 310 such askeyboard, mouse, pen, voice input device, or touch input device.Input/output system 306 may also include an output device 312, such as adisplay, speakers, or a printer.

Processor 302 may be capable of performing functions associated withtelecommunications, such as functions for processing broadcast messages,as described herein. For example, processor 302 may be capable of, inconjunction with any other portion of network device 300, determining atype of broadcast message and acting according to the broadcast messagetype or content, as described herein.

Memory 304 of network device 300 may comprise a storage medium having aconcrete, tangible, physical structure. As is known, a signal does nothave a concrete, tangible, physical structure. Memory 304, as well asany computer-readable storage medium described herein, is not to beconstrued as a signal. Memory 304, as well as any computer-readablestorage medium described herein, is not to be construed as a transientsignal. Memory 304, as well as any computer-readable storage mediumdescribed herein, is not to be construed as a propagating signal. Memory304, as well as any computer-readable storage medium described herein,is to be construed as an article of manufacture.

Memory 304 may store any information utilized in conjunction withtelecommunications. Depending upon the exact configuration or type ofprocessor, memory 304 may include a volatile storage 314 (such as sometypes of RAM), a nonvolatile storage 316 (such as ROM, flash memory), ora combination thereof. Memory 304 may include additional storage (e.g.,a removable storage 318 or a nonremovable storage 320) including, forexample, tape, flash memory, smart cards, CD-ROM, DVD, or other opticalstorage, magnetic cassettes, magnetic tape, magnetic disk storage orother magnetic storage devices, USB-compatible memory, or any othermedium that can be used to store information and that can be accessed bynetwork device 300. Memory 304 may comprise executable instructionsthat, when executed by processor 302, cause processor 302 to effectuateoperations to map signal strengths in an area of interest.

FIG. 18 illustrates a functional block diagram depicting one example ofan LTE-EPS network architecture 400 related to the current disclosure.In particular, the network architecture 400 disclosed herein is referredto as a modified LTE-EPS architecture 400 to distinguish it from atraditional LTE-EPS architecture.

An example modified LTE-EPS architecture 400 is based at least in parton standards developed by the 3rd Generation Partnership Project (3GPP),with information available at www.3gpp.org. In one embodiment, theLTE-EPS network architecture 400 includes an access network 402, a corenetwork 404, e.g., an EPC or Common BackBone (CBB) and one or moreexternal networks 406, sometimes referred to as PDN or peer entities.Different external networks 406 can be distinguished from each other bya respective network identifier, e.g., a label according to DNS namingconventions describing an access point to the PDN. Such labels can bereferred to as Access Point Names (APN). External networks 406 caninclude one or more trusted and non-trusted external networks such as aninternet protocol (IP) network 408, an IP multimedia subsystem (IMS)network 410, and other networks 412, such as a service network, acorporate network, or the like.

Access network 402 can include an LTE network architecture sometimesreferred to as Evolved Universal mobile Telecommunication systemTerrestrial Radio Access (E UTRA) and evolved UMTS Terrestrial RadioAccess Network (E-UTRAN). Broadly, access network 402 can include one ormore communication devices, commonly referred to as UE 414, and one ormore wireless access nodes, or base stations 416 a, 416 b. Duringnetwork operations, at least one base station 416 communicates directlywith UE 414. Base station 416 can be an evolved Node B (eNodeB), withwhich UE 414 communicates over the air and wirelessly. UEs 414 caninclude, without limitation, wireless devices, e.g., satellitecommunication systems, portable digital assistants (PDAs), laptopcomputers, tablet devices, Internet-of-things (IoT) devices, and othermobile devices (e.g., cellular telephones, smart appliances, and so on).UEs 414 can connect to eNBs 416 when UE 414 is within range according toa corresponding wireless communication technology.

UE 414 generally runs one or more applications that engage in a transferof packets between UE 414 and one or more external networks 406. Suchpacket transfers can include one of downlink packet transfers fromexternal network 406 to UE 414, uplink packet transfers from UE 414 toexternal network 406 or combinations of uplink and downlink packettransfers. Applications can include, without limitation, web browsing,VoIP, streaming media, and the like. Each application can pose differentQuality of Service (QoS) requirements on a respective packet transfer.Different packet transfers can be served by different bearers withincore network 404, e.g., according to parameters, such as the QoS.

Core network 404 uses a concept of bearers, e.g., EPS bearers, to routepackets, e.g., IP traffic, between a particular gateway in core network404 and UE 414. A bearer refers generally to an IP packet flow with adefined QoS between the particular gateway and UE 414. Access network402, e.g., E UTRAN, and core network 404 together set up and releasebearers as required by the various applications. Bearers can beclassified in at least two different categories: (i) minimum guaranteedbit rate bearers, e.g., for applications, such as VoIP; and (ii)non-guaranteed bit rate bearers that do not require guarantee bit rate,e.g., for applications, such as web browsing.

In one embodiment, the core network 404 includes various networkentities, such as MME 418, SGW 420, Home Subscriber Server (HSS) 422,Policy and Charging Rules Function (PCRF) 424 and PGW 426. In oneembodiment, MME 418 comprises a control node performing a controlsignaling between various equipment and devices in access network 402and core network 404. The protocols running between UE 414 and corenetwork 404 are generally known as Non-Access Stratum (NAS) protocols.

For illustration purposes only, the terms MME 418, SGW 420, HSS 422 andPGW 426, and so on, can be server devices, but may be referred to in thesubject disclosure without the word “server.” It is also understood thatany form of such servers can operate in a device, system, component, orother form of centralized or distributed hardware and software. It isfurther noted that these terms and other terms such as bearer paths orinterfaces are terms that can include features, methodologies, or fieldsthat may be described in whole or in part by standards bodies such asthe 3GPP. It is further noted that some or all embodiments of thesubject disclosure may in whole or in part modify, supplement, orotherwise supersede final or proposed standards published andpromulgated by 3GPP.

According to traditional implementations of LTE-EPS architectures, SGW420 routes and forwards all user data packets. SGW 420 also acts as amobility anchor for user plane operation during handovers between basestations, e.g., during a handover from first eNB 416 a to second eNB 416b as may be the result of UE 414 moving from one area of coverage, e.g.,cell, to another. SGW 420 can also terminate a downlink data path, e.g.,from external network 406 to UE 414 in an idle state and trigger apaging operation when downlink data arrives for UE 414. SGW 420 can alsobe configured to manage and store a context for UE 414, e.g., includingone or more of parameters of the IP bearer service and network internalrouting information. In addition, SGW 420 can perform administrativefunctions, e.g., in a visited network, such as collecting informationfor charging (e.g., the volume of data sent to or received from theuser), or replicate user traffic, e.g., to support a lawfulinterception. SGW 420 also serves as the mobility anchor forinterworking with other 3GPP technologies such as universal mobiletelecommunication system (UMTS).

At any given time, UE 414 is generally in one of three different states:detached, idle, or active. The detached state is typically a transitorystate in which UE 414 is powered on but is engaged in a process ofsearching and registering with network 402. In the active state, UE 414is registered with access network 402 and has established a wirelessconnection, e.g., radio resource control (RRC) connection, with eNB 416.Whether UE 414 is in an active state can depend on the state of a packetdata session, and whether there is an active packet data session. In theidle state, UE 414 is generally in a power conservation state in whichUE 414 typically does not communicate packets. When UE 414 is idle, SGW420 can terminate a downlink data path, e.g., from one peer entity 406,and triggers paging of UE 414 when data arrives for UE 414. If UE 414responds to the page, SGW 420 can forward the IP packet to eNB 416 a.

HSS 422 can manage subscription-related information for a user of UE414. For example, HSS 422 can store information such as authorization ofthe user, security requirements for the user, quality of service (QoS)requirements for the user, etc. HSS 422 can also hold information aboutexternal networks 406 to which the user can connect, e.g., in the formof an APN of external networks 406. For example, MME 418 can communicatewith HSS 422 to determine if UE 414 is authorized to establish a call,e.g., a voice over IP (VoIP) call before the call is established.

PCRF 424 can perform QoS management functions and policy control. PCRF424 is responsible for policy control decision-making, as well as forcontrolling the flow-based charging functionalities in a policy controlenforcement function (PCEF), which resides in PGW 426. PCRF 424 providesthe QoS authorization, e.g., QoS class identifier and bit rates thatdecide how a certain data flow will be treated in the PCEF and ensuresthat this is in accordance with the user's subscription profile.

PGW 426 can provide connectivity between the UE 414 and one or more ofthe external networks 406. In illustrative network architecture 400, PGW426 can be responsible for IP address allocation for UE 414, as well asone or more of QoS enforcement and flow-based charging, e.g., accordingto rules from the PCRF 424. PGW 426 is also typically responsible forfiltering downlink user IP packets into the different QoS-based bearers.In at least some embodiments, such filtering can be performed based ontraffic flow templates. PGW 426 can also perform QoS enforcement, e.g.,for guaranteed bit rate bearers. PGW 426 also serves as a mobilityanchor for interworking with non-3GPP technologies such as CDMA2000.

Within access network 402 and core network 404 there may be variousbearer paths/interfaces, e.g., represented by solid lines 428 and 430.Some of the bearer paths can be referred to by a specific label. Forexample, solid line 428 can be considered an S1-U bearer and solid line432 can be considered an S5/S8 bearer according to LTE-EPS architecturestandards. Without limitation, reference to various interfaces, such asS1, X2, S5, S8, S11 refer to EPS interfaces. In some instances, suchinterface designations are combined with a suffix, e.g., a “U” or a “C”to signify whether the interface relates to a “User plane” or a “Controlplane.” In addition, the core network 404 can include various signalingbearer paths/interfaces, e.g., control plane paths/interfacesrepresented by dashed lines 430, 434, 436, and 438. Some of thesignaling bearer paths may be referred to by a specific label. Forexample, dashed line 430 can be considered as an S1-MME signalingbearer, dashed line 434 can be considered as an S11 signaling bearer anddashed line 436 can be considered as an S6a signaling bearer, e.g.,according to LTE-EPS architecture standards. The above bearer paths andsignaling bearer paths are only illustrated as examples and it should benoted that additional bearer paths and signaling bearer paths may existthat are not illustrated.

Also shown is a novel user plane path/interface, referred to as theS1-U+ interface 466. In the illustrative example, the S1-U+ user planeinterface extends between the eNB 416 a and PGW 426. Notably, S1-U+path/interface does not include SGW 420, a node that is otherwiseinstrumental in configuring or managing packet forwarding between eNB416 a and one or more external networks 406 by way of PGW 426. Asdisclosed herein, the S1-U+ path/interface facilitates autonomouslearning of peer transport layer addresses by one or more of the networknodes to facilitate a self-configuring of the packet forwarding path. Inparticular, such self-configuring can be accomplished during handoversin most scenarios so as to reduce any extra signaling load on the S/PGWs420, 426 due to excessive handover events.

In some embodiments, PGW 426 is coupled to storage device 440, shown inphantom. Storage device 440 can be integral to one of the network nodes,such as PGW 426, for example, in the form of internal memory or diskdrive. It is understood that storage device 440 can include registerssuitable for storing address values. Alternatively or in addition,storage device 440 can be separate from PGW 426, for example, as anexternal hard drive, a flash drive, or network storage.

Storage device 440 selectively stores one or more values relevant to theforwarding of packet data. For example, storage device 440 can storeidentities or addresses of network entities, such as any of networknodes 418, 420, 422, 424, and 426, eNBs 416 or UE 414. In theillustrative example, storage device 440 includes a first storagelocation 442 and a second storage location 444. First storage location442 can be dedicated to storing a Currently Used Downlink address value442. Likewise, second storage location 444 can be dedicated to storing aDefault Downlink Forwarding address value 444. PGW 426 can read or writevalues into either of storage locations 442, 444, for example, managingCurrently Used Downlink Forwarding address value 442 and DefaultDownlink Forwarding address value 444 as disclosed herein.

In some embodiments, the Default Downlink Forwarding address for eachEPS bearer is the SGW S5-U address for each EPS Bearer. The CurrentlyUsed Downlink Forwarding address” for each EPS bearer in PGW 426 can beset every time when PGW 426 receives an uplink packet, e.g., a GTP-Uuplink packet, with a new source address for a corresponding EPS bearer.When UE 414 is in an idle state, the “Current Used Downlink Forwardingaddress” field for each EPS bearer of UE 414 can be set to a “null” orother suitable value.

In some embodiments, the Default Downlink Forwarding address is onlyupdated when PGW 426 receives a new SGW S5-U address in a predeterminedmessage or messages. For example, the Default Downlink Forwardingaddress is only updated when PGW 426 receives one of a Create SessionRequest, Modify Bearer Request and Create Bearer Response messages fromSGW 420.

As values 442, 444 can be maintained and otherwise manipulated on a perbearer basis, it is understood that the storage locations can take theform of tables, spreadsheets, lists, or other data structures generallywell understood and suitable for maintaining or otherwise manipulateforwarding addresses on a per bearer basis.

It should be noted that access network 402 and core network 404 areillustrated in a simplified block diagram in FIG. 18 . In other words,either or both of access network 402 and the core network 404 caninclude additional network elements that are not shown, such as variousrouters, switches, and controllers. In addition, although FIG. 18illustrates only a single one of each of the various network elements,it should be noted that access network 402 and core network 404 caninclude any number of the various network elements. For example, corenetwork 404 can include a pool (i.e., more than one) of MMEs 418, SGWs420 or PGWs 426.

In the illustrative example, data traversing a network path between UE414, eNB 416 a, SGW 420, PGW 426 and external network 406 may beconsidered to constitute data transferred according to an end-to-end IPservice. However, for the present disclosure, to properly performestablishment management in LTE-EPS network architecture 400, the corenetwork, data bearer portion of the end-to-end IP service is analyzed.

An establishment may be defined herein as a connection set up requestbetween any two elements within LTE-EPS network architecture 400. Theconnection set up request may be for user data or for signaling. Afailed establishment may be defined as a connection set up request thatwas unsuccessful. A successful establishment may be defined as aconnection set up request that was successful.

In one embodiment, a data bearer portion comprises a first portion(e.g., a data radio bearer 446) between UE 414 and eNB 416 a, a secondportion (e.g., an 51 data bearer 428) between eNB 416 a and SGW 420, anda third portion (e.g., an S5/S8 bearer 432) between SGW 420 and PGW 426.Various signaling bearer portions are also illustrated in FIG. 18 . Forexample, a first signaling portion (e.g., a signaling radio bearer 448)between UE 414 and eNB 416 a, and a second signaling portion (e.g., S1signaling bearer 430) between eNB 416 a and MME 418.

In at least some embodiments, the data bearer can include tunneling,e.g., IP tunneling, by which data packets can be forwarded in anencapsulated manner, between tunnel endpoints. Tunnels, or tunnelconnections can be identified in one or more nodes of network 400, e.g.,by one or more of tunnel endpoint identifiers, an IP address, and a userdatagram protocol port number. Within a particular tunnel connection,payloads, e.g., packet data, which may or may not include protocolrelated information, are forwarded between tunnel endpoints.

An example of first tunnel solution 450 includes a first tunnel 452 abetween two tunnel endpoints 454 a and 456 a, and a second tunnel 452 bbetween two tunnel endpoints 454 b and 456 b. In the illustrativeexample, first tunnel 452 a is established between eNB 416 a and SGW420. Accordingly, first tunnel 452 a includes a first tunnel endpoint454 a corresponding to an S1-U address of eNB 416 a (referred to hereinas the eNB S1-U address), and second tunnel endpoint 456 a correspondingto an S1-U address of SGW 420 (referred to herein as the SGW S1-Uaddress). Likewise, second tunnel 452 b includes first tunnel endpoint454 b corresponding to an S5-U address of SGW 420 (referred to herein asthe SGW S5-U address), and second tunnel endpoint 456 b corresponding toan S5-U address of PGW 426 (referred to herein as the PGW S5-U address).

In at least some embodiments, first tunnel solution 450 is referred toas a two-tunnel solution, e.g., according to the GPRS Tunneling ProtocolUser Plane (GTPv1-U based), as described in 3GPP specification TS29.281, incorporated herein in its entirety. It is understood that oneor more tunnels are permitted between each set of tunnel end points. Forexample, each subscriber can have one or more tunnels, e.g., one foreach PDP context that they have active, as well as possibly havingseparate tunnels for specific connections with different quality ofservice requirements, and so on.

An example of second tunnel solution 458 includes a single or directtunnel 460 between tunnel endpoints 462 and 464. In the illustrativeexample, direct tunnel 460 is established between eNB 416 a and PGW 426,without subjecting packet transfers to processing related to SGW 420.Accordingly, direct tunnel 460 includes first tunnel endpoint 462corresponding to the eNB S1-U address, and second tunnel endpoint 464corresponding to the PGW S5-U address. Packet data received at eitherend can be encapsulated into a payload and directed to the correspondingaddress of the other end of the tunnel. Such direct tunneling avoidsprocessing, e.g., by SGW 420 that would otherwise relay packets betweenthe same two endpoints, e.g., according to a protocol, such as the GTP-Uprotocol.

In some scenarios, direct tunneling solution 458 can forward user planedata packets between eNB 416 a and PGW 426, by way of SGW 420. Forexample, SGW 420 can serve a relay function, by relaying packets betweentwo tunnel endpoints 416 a, 426. In other scenarios, direct tunnelingsolution 458 can forward user data packets between eNB 416 a and PGW426, by way of the S1 U+ interface, thereby bypassing SGW 420.

Generally, UE 414 can have one or more bearers at any one time. Thenumber and types of bearers can depend on applications, defaultrequirements, and so on. It is understood that the techniques disclosedherein, including the configuration, management and use of varioustunnel solutions 450, 458, can be applied to the bearers on anindividual basis. For example, if user data packets of one bearer, say abearer associated with a VoIP service of UE 414, then the forwarding ofall packets of that bearer are handled in a similar manner. Continuingwith this example, the same UE 414 can have another bearer associatedwith it through the same eNB 416 a. This other bearer, for example, canbe associated with a relatively low rate data session forwarding userdata packets through core network 404 simultaneously with the firstbearer. Likewise, the user data packets of the other bearer are alsohandled in a similar manner, without necessarily following a forwardingpath or solution of the first bearer. Thus, one of the bearers may beforwarded through direct tunnel 458; whereas, another one of the bearersmay be forwarded through a two-tunnel solution 450.

As shown in FIG. 19 , telecommunication system 600 may include wirelesstransmit/receive units (WTRUs) 602, a RAN 604, a core network 606, apublic switched telephone network (PSTN) 608, the Internet 610, or othernetworks 612, though it will be appreciated that the disclosed examplescontemplate any number of WTRUs, base stations, networks, or networkelements. Each WTRU 602 may be any type of device configured to operateor communicate in a wireless environment. For example, a WTRU maycomprise IoT devices 32, mobile devices 33, network device 300, or thelike, or any combination thereof. By way of example, WTRUs 602 may beconfigured to transmit or receive wireless signals and may include a UE,a mobile station, a mobile device, a fixed or mobile subscriber unit, apager, a cellular telephone, a PDA, a smartphone, a laptop, a netbook, apersonal computer, a wireless sensor, consumer electronics, or the like.WTRUs 602 may be configured to transmit or receive wireless signals overan air interface 614.

Telecommunication system 600 may also include one or more base stations616. Each of base stations 616 may be any type of device configured towirelessly interface with at least one of the WTRUs 602 to facilitateaccess to one or more communication networks, such as core network 606,PTSN 608, Internet 610, or other networks 612. By way of example, basestations 616 may be a base transceiver station (BTS), a Node-B, aneNodeB, a Home Node B, a Home eNodeB, a site controller, an access point(AP), a wireless router, or the like. While base stations 616 are eachdepicted as a single element, it will be appreciated that base stations616 may include any number of interconnected base stations or networkelements.

RAN 604 may include one or more base stations 616, along with othernetwork elements (not shown), such as a base station controller (BSC), aradio network controller (RNC), or relay nodes. One or more basestations 616 may be configured to transmit or receive wireless signalswithin a particular geographic region, which may be referred to as acell (not shown). The cell may further be divided into cell sectors. Forexample, the cell associated with base station 616 may be divided intothree sectors such that base station 616 may include three transceivers:one for each sector of the cell. In another example, base station 616may employ multiple-input multiple-output (MIMO) technology and,therefore, may utilize multiple transceivers for each sector of thecell.

Base stations 616 may communicate with one or more of WTRUs 602 over airinterface 614, which may be any suitable wireless communication link(e.g., RF, microwave, infrared (IR), ultraviolet (UV), or visiblelight). Air interface 614 may be established using any suitable radioaccess technology (RAT).

More specifically, as noted above, telecommunication system 600 may be amultiple access system and may employ one or more channel accessschemes, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, or the like. Forexample, base station 616 in RAN 604 and WTRUs 602 connected to RAN 604may implement a radio technology such as Universal MobileTelecommunications System (UMTS) Terrestrial Radio Access (UTRA) thatmay establish air interface 614 using wideband CDMA (WCDMA). WCDMA mayinclude communication protocols, such as High-Speed Packet Access (HSPA)or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink PacketAccess (HSDPA) or High-Speed Uplink Packet Access (HSUPA).

As another example base station 616 and WTRUs 602 that are connected toRAN 604 may implement a radio technology such as Evolved UMTSTerrestrial Radio Access (E-UTRA), which may establish air interface 614using LTE or LTE-Advanced (LTE-A).

Optionally base station 616 and WTRUs 602 connected to RAN 604 mayimplement radio technologies such as IEEE 602.16 (i.e., WorldwideInteroperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1×,CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95(IS-95), Interim Standard 856 (IS-856), GSM, Enhanced Data rates for GSMEvolution (EDGE), GSM EDGE (GERAN), or the like.

Base station 616 may be a wireless router, Home Node B, Home eNodeB, oraccess point, for example, and may utilize any suitable RAT forfacilitating wireless connectivity in a localized area, such as a placeof business, a home, a vehicle, a campus, or the like. For example, basestation 616 and associated WTRUs 602 may implement a radio technologysuch as IEEE 602.11 to establish a wireless local area network (WLAN).As another example, base station 616 and associated WTRUs 602 mayimplement a radio technology such as IEEE 602.15 to establish a wirelesspersonal area network (WPAN). In yet another example, base station 616and associated WTRUs 602 may utilize a cellular-based RAT (e.g., WCDMA,CDMA2000, GSM, LTE, LTE-A, etc.) to establish a picocell or femtocell.As shown in FIG. 20 , base station 616 may have a direct connection toInternet 610. Thus, base station 616 may not be required to accessInternet 610 via core network 606.

RAN 604 may be in communication with core network 606, which may be anytype of network configured to provide voice, data, applications, orvoice over internet protocol (VoIP) services to one or more WTRUs 602.For example, core network 606 may provide call control, billingservices, mobile location-based services, pre-paid calling, Internetconnectivity, video distribution or high-level security functions, suchas user authentication. Although not shown in FIG. 20 , it will beappreciated that RAN 604 or core network 606 may be in direct orindirect communication with other RANs that employ the same RAT as RAN604 or a different RAT. For example, in addition to being connected toRAN 604, which may be utilizing an E-UTRA radio technology, core network606 may also be in communication with another RAN (not shown) employinga GSM radio technology.

Core network 606 may also serve as a gateway for WTRUs 602 to accessPSTN 608, Internet 610, or other networks 612. PSTN 608 may includecircuit-switched telephone networks that provide plain old telephoneservice (POTS). For LTE core networks, core network 606 may use IMS core614 to provide access to PSTN 608. Internet 610 may include a globalsystem of interconnected computer networks or devices that use commoncommunication protocols, such as the transmission control protocol(TCP), user datagram protocol (UDP), or IP in the TCP/IP internetprotocol suite. Other networks 612 may include wired or wirelesscommunications networks owned or operated by other service providers.For example, other networks 612 may include another core networkconnected to one or more RANs, which may employ the same RAT as RAN 604or a different RAT.

Some or all WTRUs 602 in telecommunication system 600 may includemulti-mode capabilities. For example, WTRUs 602 may include multipletransceivers for communicating with different wireless networks overdifferent wireless links. For example, one or more WTRUs 602 may beconfigured to communicate with base station 616, which may employ acellular-based radio technology, and with base station 616, which mayemploy an IEEE 802 radio technology.

FIG. 20 is an example system 700 including RAN 604 and core network 606.As noted above, RAN 604 may employ an E-UTRA radio technology tocommunicate with WTRUs 602 over air interface 614. RAN 604 may also bein communication with core network 606.

RAN 604 may include any number of eNodeBs 702 while remaining consistentwith the disclosed technology. One or more eNodeBs 702 may include oneor more transceivers for communicating with the WTRUs 602 over airinterface 614. Optionally, eNodeBs 702 may implement MIMO technology.Thus, one of eNodeBs 702, for example, may use multiple antennas totransmit wireless signals to, or receive wireless signals from, one ofWTRUs 602.

Each of eNodeBs 702 may be associated with a particular cell (not shown)and may be configured to handle radio resource management decisions,handover decisions, scheduling of users in the uplink or downlink, orthe like. As shown in FIG. 20 eNodeBs 702 may communicate with oneanother over an X2 interface.

Core network 606 shown in FIG. 20 may include a mobility managementgateway or entity (MME) 704, a serving gateway 706, or a packet datanetwork (PDN) gateway 708. While each of the foregoing elements aredepicted as part of core network 606, it will be appreciated that anyone of these elements may be owned or operated by an entity other thanthe core network operator.

MME 704 may be connected to each of eNodeBs 702 in RAN 604 via an S1interface and may serve as a control node. For example, MME 704 may beresponsible for authenticating users of WTRUs 602, bearer activation ordeactivation, selecting a particular serving gateway during an initialattach of WTRUs 602, or the like. MME 704 may also provide a controlplane function for switching between RAN 604 and other RANs (not shown)that employ other radio technologies, such as GSM or WCDMA.

Serving gateway 706 may be connected to each of eNodeBs 702 in RAN 604via the S1 interface. Serving gateway 706 may generally route or forwarduser data packets to or from the WTRUs 602. Serving gateway 706 may alsoperform other functions, such as anchoring user planes duringinter-eNodeB handovers, triggering paging when downlink data isavailable for WTRUs 602, managing or storing contexts of WTRUs 602, orthe like.

Serving gateway 706 may also be connected to PDN gateway 708, which mayprovide WTRUs 602 with access to packet-switched networks, such asInternet 610, to facilitate communications between WTRUs 602 andIP-enabled devices.

Core network 606 may facilitate communications with other networks. Forexample, core network 606 may provide WTRUs 602 with access tocircuit-switched networks, such as PSTN 608, such as through IMS core614, to facilitate communications between WTRUs 602 and traditionalland-line communications devices. In addition, core network 606 mayprovide the WTRUs 602 with access to other networks 612, which mayinclude other wired or wireless networks that are owned or operated byother service providers.

While examples of described telecommunications system have beendescribed in connection with various computing devices/processors, theunderlying concepts may be applied to any computing device, processor,or system capable of facilitating a telecommunications system. Thevarious techniques described herein may be implemented in connectionwith hardware or software or, where appropriate, with a combination ofboth. Thus, the methods and devices may take the form of program code(i.e., instructions) embodied in concrete, tangible, storage mediahaving a concrete, tangible, physical structure. Examples of tangiblestorage media include floppy diskettes, CD-ROMs, DVDs, hard drives, orany other tangible machine-readable storage medium (computer-readablestorage medium). Thus, a computer-readable storage medium is not asignal. A computer-readable storage medium is not a transient signal.Further, a computer-readable storage medium is not a propagating signal.A computer-readable storage medium as described herein is an article ofmanufacture. When the program code is loaded into and executed by amachine, such as a computer, the machine becomes a device fortelecommunications. In the case of program code execution onprogrammable computers, the computing device will generally include aprocessor, a storage medium readable by the processor (includingvolatile or nonvolatile memory or storage elements), at least one inputdevice, and at least one output device. The program(s) can beimplemented in assembly or machine language, if desired. The languagecan be a compiled or interpreted language and may be combined withhardware implementations.

The methods and devices associated with a telecommunications system asdescribed herein also may be practiced via communications embodied inthe form of program code that is transmitted over some transmissionmedium, such as over electrical wiring or cabling, through fiber optics,or via any other form of transmission, wherein, when the program code isreceived and loaded into and executed by a machine, such as an EPROM, agate array, a programmable logic device (PLD), a client computer, or thelike, the machine becomes an device for implementing telecommunicationsas described herein. When implemented on a general-purpose processor,the program code combines with the processor to provide a unique devicethat operates to invoke the functionality of a telecommunicationssystem.

While a telecommunications system has been described in connection withthe various examples of the various figures, it is to be understood thatother similar implementations may be used, or modifications andadditions may be made to the described examples of a telecommunicationssystem without deviating therefrom. For example, one skilled in the artwill recognize that a telecommunications system as described in theinstant application may apply to any environment, whether wired orwireless, and may be applied to any number of such devices connected viaa communications network and interacting across the network. Therefore,a telecommunications system as described herein should not be limited toany single example, but rather should be construed in breadth and scopein accordance with the appended claims. The term “or” as used herein isinclusive, unless provided otherwise.

1. A device, comprising: a processor; and a memory coupled with theprocessor, the memory storing executable instructions that, whenexecuted by the processor, cause the processor to effectuate operationscomprising: obtaining, from a network support system associated with atelecommunications network, workflow information that identifies networkresources associated with a process of the telecommunications network;deploying, based on the workflow information, one or more roboticprocess automation (RPA) BOTs in the telecommunications network, whereinthe workflow information instructs the one or more RPA BOTs to obtaindiagnostic information regarding the telecommunications network;gathering RPA BOT performance data associated with a performance of theone or more RPA BOTs using virtual machines deployed in thetelecommunications network; analyzing a status of the one or more RPABOTs based on the RPA BOT performance data; managing the one or more RPABOTs based on the status, wherein the managing includes starting,stopping, or rebooting an RPA BOT in the telecommunications networkbased on the status; monitoring multiple hosted virtual disks (HVDs) forreadiness for use; and providing a graphical user interface forfacilitating further management of the one or more RPA BOTs in relationto the multiple HVDs, wherein the graphical user interface provides alisting of the multiple HVDs being monitored, information regarding amonitored capacity of each HVD of the multiple HVDs, and a scheduleidentifying scheduled and available timeslots for the monitored capacityof each HVD of the multiple HVDs.
 2. The device of claim 1, wherein themanaging the one or more RPA BOTs comprises performing one or moreactions on the telecommunications network or the one or more RPA BOTs,wherein the obtaining the workflow information comprises obtaining theworkflow information from an input file drop, and wherein the operationsfurther comprise providing fallout information to a fallout file dropfor transmission to the input file drop.
 3. The device of claim 2,wherein the one or more actions comprise identifying a BOT failure causeor identifying a record processing failure cause.
 4. The device of claim1, wherein the managing the one or more RPA BOTs comprises providing oneor more alerts based on the analyzing the status of the one or more RPABOTs, conducting HVD management, or providing reporting and analyticsbased on the analyzing the status of the one or more RPA BOTs.
 5. Thedevice of claim 1, wherein at least some of the one or more RPA BOTs areschedulable to a given HVD of the multiple HVDs according to theschedule thereof for maintenance so as to avoid HVD underutilization oroverutilization.
 6. The device of claim 1, wherein the analyzing thestatus of the one or more RPA BOTs comprises comparing RPA BOTinformation derived from the RPA BOT performance data to at least oneservice level agreement (SLA).
 7. The device of claim 6, wherein theoperations further comprise determining a performance of the one or moreRPA BOTs based on the comparing the RPA BOT information derived from theRPA BOT performance data to the at least one SLA.
 8. Acomputer-implemented method comprising: obtaining, from a networksupport system associated with a telecommunications network, workflowinformation that identifies network resources associated with a processof the telecommunications network; deploying, based on the workflowinformation, one or more robotic process automation (RPA) BOTs in thetelecommunications network, wherein the workflow information isgenerated and included in a flat file transmitted by the network supportsystem; gathering RPA BOT performance data associated with a performanceof the one or more RPA BOTs using virtual machines deployed in thetelecommunications network; analyzing a status of the one or more RPABOTs based on the RPA BOT performance data; managing the one or more RPABOTs based on the status, wherein the managing includes starting an RPABOT in the telecommunications network based on the status; monitoring astatus of multiple hosted virtual disks (HVDs); and providing agraphical user interface for facilitating further management of the oneor more RPA BOTs in relation to the multiple HVDs, wherein the graphicaluser interface provides a listing of the multiple HVDs being monitored,information regarding a monitored capacity of each HVD of the multipleHVDs, and a schedule identifying scheduled timeslots for the monitoredcapacity of each HVD of the multiple HVDs.
 9. The computer-implementedmethod of claim 8, wherein the managing the one or more RPA BOTscomprises performing one or more actions on the telecommunicationsnetwork or the one or more RPA BOTs, wherein the obtaining the workflowinformation comprises obtaining the workflow information from an inputfile drop, and wherein the method further comprises providing falloutinformation to a fallout file drop for transmission to the input filedrop.
 10. The computer-implemented method of claim 9, wherein the one ormore actions comprise identifying a BOT failure cause or identifying arecord processing failure cause.
 11. The computer-implemented method ofclaim 8, wherein the managing the one or more RPA BOTs comprisesproviding one or more alerts based on the analyzing the status of theone or more RPA BOTs, conducting HVD management, or providing reportingand analytics based on the analyzing the status of the one or more RPABOTs.
 12. The computer-implemented method of claim 8, wherein at leastsome of the one or more RPA BOTs are schedulable to a given HVD of themultiple HVDs according to the schedule thereof for maintenance so as toavoid HVD underutilization or overutilization.
 13. Thecomputer-implemented method of claim 8, wherein the analyzing the statusof the one or more RPA BOTs comprises comparing BOT information to atleast one service level agreement (SLA).
 14. The computer-implementedmethod of claim 13, further comprising determining a performance of theone or more RPA BOTs based on the comparing the BOT information to theat least one SLA.
 15. A system comprising: a user device, wherein theuser device comprises a graphical user interface; and a managementsystem comprising: a processor; and a memory coupled with the processor,the memory storing executable instructions that, when executed by theprocessor, cause the processor to effectuate operations comprising:obtaining, from a network support system associated with atelecommunications network, workflow information that identifies networkresources associated with a process of the telecommunications network;deploying, based on the workflow information, one or more roboticprocess automation (RPA) BOTs in the telecommunications network, whereinthe workflow information instructs the one or more RPA BOTs to obtaindiagnostic information regarding the telecommunications network;gathering RPA BOT performance data associated with a performance of theone or more RPA BOTs using virtual machines deployed in thetelecommunications network; analyzing a status of the one or more RPABOTs based on the RPA BOT performance data; managing the one or more RPABOTs based on the status using the user device, wherein the managingincludes stopping an RPA BOT in the telecommunications network based onthe status; monitoring multiple hosted virtual disks (HVDs) foravailability for use; and providing the graphical user interface to theuser device for facilitating further management of the one or more RPABOTs, wherein the graphical user interface provides a listing of themultiple HVDs being monitored, information regarding a monitoredcapacity of each HVD of the multiple HVDs, and a schedule identifyingavailable timeslots for the monitored capacity of each HVD of themultiple HVDs.
 16. The system of claim 15, wherein the managing the oneor more RPA BOTs comprises performing one or more actions on thetelecommunications network or the one or more RPA B OTs, wherein theobtaining the workflow information comprises obtaining the workflowinformation from an input file drop, and wherein the operations furthercomprise providing fallout information to a fallout file drop fortransmission to the input file drop.
 17. The system of claim 16, whereinthe one or more actions comprise identifying a BOT failure cause oridentifying a record processing failure cause.
 18. The system of claim15, wherein the managing the one or more RPA BOTs comprises providingone or more alerts based on the analyzing the status of the one or moreRPA BOTs, conducting HVD management, or providing reporting andanalytics based on the analyzing the status of the one or more RPA BOTs.19. The system of claim 15, wherein the analyzing the status of the oneor more RPA BOTs comprises comparing RPA BOT information derived fromthe RPA BOT performance data to at least one service level agreement(SLA).
 20. The system of claim 19, wherein the operations furthercomprise determining a performance of the one or more RPA BOTs based onthe comparing the RPA BOT information derived from the RPA BOTperformance data to the at least one SLA.